When the bundle repair worker re-queues a bundle (because some of its
children were dropped at the data-item indexer's queue cap on a prior
attempt), the parser previously re-emitted EVERY child — including the
90%+ that were already indexed. Each redundant emit consumed a slot in
the dataItemIndexer / ans104DataIndexer queues, contending with the
genuinely-new children for the cap. Under sustained backfill load this
was the dominant contributor to the 2M+ items dropped per hour
observed on the Turbo gw2 indexer.

The fix: before parsing, the Ans104Unbundler queries the BundleIndex
for the set of ids already present in new_data_items or
stable_data_items under this parent. The set is passed to the parser
worker. For each parsed item whose id is in the set, the parser
increments matchedItemCount (preserving the bundle's
matched_data_item_count invariant — see below) and skips the
filter eval, hash, and DATA_ITEM_MATCHED emit. Net effect: redundant
queue traffic disappears and the downstream queues breathe.

matched_data_item_count invariant: upsertBundle uses
`IFNULL(@matched, matched)` to update the column, and the
fully-indexed predicate is strict equality between bundle_data_items
row count and matched_data_item_count. If we lowered the emitted
matched count by the skip amount, the new lower value would replace
the existing one and the equality would never hold (rows >
matched_data_item_count from then on, so fully_indexed_at never sets).
Counting skips toward matchedItemCount avoids this. Assumption: the
unbundle/index filter has not changed between parses — when filters
do change, the filter-reprocess path clears the bundle separately and
skipChildIds is empty for those.

Failure handling: if getIndexedChildIds throws, we log and proceed
without a skip-set rather than failing the unbundle. Worst case is
the pre-fix behavior of redundant emits, not a regression.

Five-edit DB plumbing for `selectIndexedChildIds` + `getIndexedChildIds`:
SQL, worker impl, queue wrapper, message handler, BundleIndex interface.

Tests cover three cases:
- no bundleIndex provided -> skipChildIds undefined (unchanged behavior)
- bundleIndex returns ids -> skipChildIds passed to parser
- bundleIndex throws -> skipChildIds undefined, unbundle still proceeds

Companion to PE-9098-bundle-repair-bdi-routing (the previous PR);
together they address the BDI repair pipeline end-to-end.

Two refinements to the parser-skip-already-indexed work, addressing
feedback from review:

1. **Tighten the predicate to `data_offset IS NOT NULL`** on both
   `new_data_items` and `stable_data_items`. The optimistic insert
   path (insertOrIgnoreNewDataItem, used by the admin
   `/queue-data-item` route) intentionally leaves the eleven root-atom
   columns NULL — including `data_offset` — expecting a subsequent
   full parser-emit to fill them via the COALESCE/IFNULL clauses in
   upsertNewDataItem's `ON CONFLICT UPDATE`. Without this predicate,
   our skip-set would include optimistically-inserted rows and strand
   their tuple fields permanently NULL across re-parses. With it, we
   only skip rows whose tuple fields are already populated — the case
   where re-emit is a true no-op.

   Cost: the existing covering indexes `(parent_id, id)` no longer
   cover the query (data_offset isn't in the index). Each row pays one
   extra page read. For a 10K-child bundle, ~10K extra heap reads.
   Still fast (sub-100ms worst case). If this becomes hot we can add a
   partial index `(parent_id, id) WHERE data_offset IS NOT NULL`.

2. **Add `bundles_data_items_skipped_already_indexed_total`** counter.
   Wired from the `ANS104_UNBUNDLE_COMPLETE` event handler off the
   `alreadyIndexedSkippedCount` value the parser already includes in
   its completion message. No label — the only realistic value would
   be `bundle_format` and ANS-104 is the only format in production
   use; an unused dimension on a Prometheus metric is just clutter.

Tests unchanged (12 pass). Build + lint clean.